Перед самой конференцией VMworld 2019, которая прошла на прошлой неделе в Сан-Франциско, компания VMware анонсировала полезный сервис ports.vmware.com, где любой желающий может вывести порты и соединения по различным протоколам для следующих продуктов серверной линейки:
vSphere
vSAN
NSX for vSphere
vRealize Network Insight
vRealize Operations Manager
vRealize Automation
Выглядит это вот таким образом (кликабельно):
Как мы видим, в левой части можно выбрать один или несколько продуктов, для которых будут выведены все соединения с указанием портов и характера взаимодействий. Это позволит правильно настроить сетевые экраны, через которые происходит коммуникация между компонентами виртуальной инфраструктуры.
Результаты можно вывести в отдельный красивый PDF-документ, либо распечатать. Что удобно, в колонке version указана версия продукта, для которой эта информация актуальна.
Если раньше всю эту информацию приходилось вылавливать из статей базы знаний VMware, а также подглядывать в различные постеры, то теперь все очень удобно организовано на одном экране (и что важно с возможностью поиска по результатам). Также есть удобная функция - сортировка по колонкам, например, по номеру порта - когда хочется найти конкретный порт или диапазон.
Многие из вас следят за новостями и событиями конференции VMworld 2019, которая проходит в эти дни в Сан-Франциско. Одним из первых и важных анонсов конференции стало объявление о скором выпуске проекта VMware Tanzu. Те из вас, кто следит в последнее время за новыми релизами от VMware, знают, что компания выпускает очень много чего интересного для инфраструктуры контейнеризованных приложений Kubernetes.
Например, совсем недавно мы писали о новой подсистеме хранения для K8s - Cloud Native Storage (CNS), утилите для контроля и мониторинга состояния кластеров VMware Octant, а также средстве для управления инфраструктурой контейнеров приложений VMware Enterprise PKS 1.5 (Pivotal Container Service).
На данный момент свежепоявившееся семейство Tanzu представлено двумя продуктами:
Project Pacific — набор средств для преобразования среды VMware vSphere в нативную платформу для кластеров Kubernetes (будет доступно в следующих релизах vSphere).
VMware Tanzu Mission Control - единая операционная консоль для кластеров Kubernetes, которая позволит контролировать все аспекты жизненного цикла приложений.
Project Pacific
Project Pacific сейчас находится в статусе технологического превью. Это средство представляет собой набор инструментов, который позволяет преобразовать платформу vSphere в средство нативного исполнения приложений в среде Kubernetes.
Данный продукт будет решать следующие задачи:
Использование vSphere для нативной среды Kubernetes
Предоставление средств управления, сфокусированных на приложениях
Возможность взаимодействия команд разработки и администрирования/оперирования
С помощью Pacific разработчики продолжат управлять приложениями посредством Kubernetes, но сами приложения за счет этого будут "комфортно себя чувствовать" на платформе ESXi. Администраторы же смогут выполнять рутинные задачи через средства управления VMware vCenter.
Так как подразумевается, что Kubernetes будет нативно работать в среде vSphere, то будет поддерживаться концепция пространств имен в рамках инфраструктуры vSphere. Пространства имен в K8s - это коллекции объектов (контейнеры, виртуальные машины, диски и т.п.).
На уровне пространств имен в среде K8s можно выполнять стандартные для vSphere операции, такие как контроль и выделение ресурсов, vMotion, шифрование, HA и снапшоты.
VMware Tanzu Mission Control
Tanzu MC дает менеджерам и администраторам датацентров средства для создания и развертывания новых приложений на платформе Kubernetes, а также дает управлять кластерами K8s из единой точки. Таким образом, команды разработки могут запросить нужные ресурсы, когда им требуется, и получить их самым быстрым и оптимальным образом.
Платформа Tanzu Mission Control полностью построена на базе универсального API, который могут использовать разработчики для оперирования кластерами Kubernetes через Cluster API. Это касается всех рабочих процессов (например, создание или обновление кластера), а также аутентификации и прочих вспомогательных сервисов.
Сама консоль - это SaaS-решение, которое объединяет объекты разной природы в облачной консоли (например, это могут быть компоненты платформы vSphere, объекты из публичных облаков, средства OpenShift или просто самопальные инсталляции собственной архитектуры). Также вы можете привязать кластер VMware Essential PKS к консоли Tanzu Mission Control и использовать средства автоматизации обслуживания жизненного цикла кластеров, либо можно открыть и использовать расширенные средства сервисов PKS-кластера.
Консоль Mission Control использует:
Cluster API для управления жизненным циклом (Lifecycle Management)
Velero для резервного копирования и восстановления
Sonobuoy для контроля конфигураций
Contour для контроля компонентов ingress
Также все кластеры и их объекты покрываются гибко настраиваемыми политиками. Их можно применять к кластерам и группам кластеров, разграничивая таким образом зоны ответственности между разработчиками.
Ну и одно из самых удобных для оператора - это федерация данных кластеров K8s из разных источников в единой консоли:
Пока мы готовим большие посты об анонсах проходящего в эти дни в Сан-Франциско VMworld 2019, расскажем о небольших обновлениях. На сайте проекта VMware Labs появился апдейт средства для управления инфраструктурой VMware vSphere с мобильного телефона - vSphere Mobile Client 1.3. Напомним, что о прошлой версии клиента Mobile Client 1.2 мы писали вот тут. Надо заметить, что обновляется он хорошими темпами.
Давайте посмотрим, что нового добавили в Mobile Client 1.3:
Наконец-то появилось представление уровня хостов - Hosts View.
Дэшборд vCenter теперь включает объекты с наибольшим числом сработавших алертов.
Для iOS-клиента появилась функция сообщения о вылетах приложения (Crash reporting).
Категории событий теперь видны в интерфейсе (что это - alarm, error или warning).
Улучшена обработка получения имени сервера vCenter.
Скачать обновленный vSphere Mobile Client 1.3 можно по этим ссылкам:
Android - до того, как устанавливать клиент, вам надо присоединиться к этой группе Google Groups, члены которой принимают участие в альфа-тестировании.
Чтобы получать пуш-уведомления на ваши устройства, нужно будет поднять vSphere Mobile Client Notification Service в виде контейнера Docker. О том, как это сделать написано тут, а скачать сам контейнер можно на странице vSphere Mobile Client.
Как вы знаете, недавно обновленная платформа виртуализации VMware vSphere 6.7 Update 3 стала доступной для загрузки. Одновременно с этим компания VMware сделала доступной для скачивания и развертывания систему отказоустойчивых кластеров хранилищ VMware vSAN 6.7 Update 3. В обоих этих решениях появилась встроенная поддержка технологии Cloud Native Storage (CNS), о которой мы сегодня расскажем.
Итак, Cloud Native Storage (CNS) - это функциональность VMware vSphere и платформы оркестрации Kubernetes (K8s), которая позволяет по запросу развертывать и обслуживать хранилища для виртуальных машин, содержащих внутри себя контейнеры. По-сути, это платформа для управления жизненным циклом хранения для контейнеризованных приложений.
При этом для такого управления сделано специальное представление в интерфейсе vCenter, которое вы видите на картинке выше.
Основная задача CNS - это обеспечивать развертывание, мониторинг и управление хранилищами для Cloud Native Applications (CNA), то есть современных приложений, исполняемых в контейнерах Docker под управлением Kubernetes (но, кстати, в будущем возможна поддержка и таких платформ, как Mesos и Docker Swarm).
Архитектура CNS реализована двумя компонентами:
Интерфейс Container Storage Interface (CSI), представляющий собой плагин для K8s.
Консоль управления CNS Control Plane на сервере vCenter, доступная через vSphere Client.
Через консоль управления CNS администратор может получить представление об имеющихся хранилищах в среде K8s (и видеть маппинги хранилищ на виртуальные диски VMDK), а также управлять ими в большом масштабе, что очень сложно при оперировании на уровне отдельных контейнеров, так как их могут быть сотни на одном хосте ESXi.
Кстати, про оперирование CNS есть интересное видео от VMware:
Надо понимать, что технология CNS появилась не впервые. Ранее подобные функции реализовывал механизм vSphere Storage for Kubernetes (он же vSphere Cloud Provider, VCP). Проект VCP появился как результат внутреннего хакатона VMware, когда требовалось быстро сделать драйвер для кластеров Kubernetes.
До этого приходилось вручную монтировать хранилища контейнеров на виртуальные диски VMDK, что было крайне неудобно, а при большом количестве контейнеров - практически нереально.
Сейчас архитектура VCP реализуется такими решениями Kubernetes as a Service (KaaS), как VMware PKS, RedHat OpenShift, Google Cloud Anthos и Rancher. Для этой архитектуры было возможно 2 режима развертывания - "in-tree" и "out-of-tree". В первом случае VCP был интегрирован в дистрибутив Kubernetes и развертывался одновременно с ним, а во втором - подразумевал последующую интеграцию после развертывания K8s.
Ввиду того, что обновлять VCP при первом варианте развертывания можно было только одновременно с K8s, вариант "in-tree" был исключен из конфигурации развертывания Kubernetes. VMware использовала эту ситуацию для того, чтобы полностью переписать код VCP (который, скорее всего, был не самым оптимальным еще с хакатона) и получить новую архитектуру - CNS.
Также кстати оказалась и покупка компании Heptio (об этом мы упоминали вот тут) - в итоге VMware интегрировала решение CNS прямо в платформу vSphere, без необходимости что-либо развертывать дополнительно. Мало того, архитектура CNS поддерживает любой оркестратор контейнеров, построенный на базе спецификации CSI.
Таким образом, CNS Control Plane на сервере vCenter брокеризует соединение с плагином (на данный момент только для K8s), который уже взаимодействует на уровне Kubernetes.
Частью решения CNS являются First Class Disks (FCDs), о которых мы рассказывали вот тут. Они были придуманы для того, чтобы управлять сервисами, заключенными в VMDK-диски, но не требующими виртуальных машин для своего постоянного существования. Это очень удобно для контейнеров, так как их можно динамически привязывать и отвязывать, не оставляя после себя "осиротевших" VMDK.
Кроме всего этого, CNS полностью подчиняется политикам Storage Policy-Based Management (SPBM), а это значит, что инфраструктура таких хранилищ отлично согласуется с пространством ярусного хранения VMware vSAN и концепцией K8s StorageClass. Также CNS, конечно же, работает и с классическими хранилищами VMFS и NFS, что позволяет использовать политики SPBM на базе тэгов.
Надо отметить, что технология CNS доступна для всех пользователей VMware vSphere, начиная с издания Standard, поэтому платить отдельно за нее не придется. Ну и в заключение обзорное видео о том, что такое и как работает Cloud Native Storage:
Скачать VMware vSphere 6.7 Update 3 с интегрированной технологией CNS можно по этой ссылке.
Перед предстоящей конференцией VMworld 2019, которая состоится на следующей неделе в Сан-Франциско, компания VMware сделала несколько небольших анонсов, чтобы они не потерялись на фоне больших. В частности, стала доступной для скачивания новая версия платформы VMware vSphere 6.7 Update 3, решение VMware vSAN 6.7 Update 3 и продукт VMware PKS 1.5. Ну а на днях было выпущено еще одно обновление фреймворка для управления виртуальной инфраструктурой через PowerShell - VMware PowerCLI 11.4.
Напомним, что о прошлой версии PowerCLI 11.3 мы писали в начале лета вот тут. Давайте посмотрим, что нового появилось в PowerCLI 11.4:
В PowerCLI 11.4 был существенно доработан модуль по работе с хранилищами, чтобы поддерживать последнюю версию продукта для создания отказоустойчивых кластеров хранилищ VMware vSAN 6.7 Update 3. Например, были обновлены командлеты Get/Set-VsanClusterConfiguration, которые теперь поддерживают функции Proactive Rebalance и vSphere Update Manager baseline preference.
Вот пример работы с этими функциями в действии (на красный текст внимание не обращайте, он говорит о том, что для работы нужен vSAN 6.7 U3):
Также появилось три новых командлета. Первый - это Add-VsanObjectToRepairQueue, он может восстанавливать объекты, которые добавляются в очередь на восстановление (ранее эта функция была частично доступна в командлете Repair-VsanObject). Второй и третий - это Get-VsanResyncingOverview и Get-VsanEnterMaintenanceMode, они работают с новыми функциями vSAN 6.7 U3.
3. Обновленный модуль HCX.
Теперь в этот модуль было добавлено целых 6 новых командлетов:
Get-HCXAppliance - возвращает информацию о текущей версии виртуального модуля и доступных версиях.
Его можно использовать с командлетом New-HCXAppliance - он позволяет проапгрейдить виртуальный модуль на одну из доступных версий.
Get-HCXContainer - добавляет возможность вывести список контейнеров типа "OrgVdc".
Get-HCXNetwork - добавляет возможность посмотреть 2 типа сетей: NsxtSegment и OrgVdcNetwork.
New-HCXNetworkExtension - дает возможность работать с сетями типа NsxtSegment.
Get-HCXServiceMesh - он имеет свойства, которые дают посмотреть параметры некоторых сервисов.
Пример использования командлетов Get-HCXAppliance и Get-HCXServiceMesh для просмотра нового свойства ServiceStatus:
Командлеты Get-HCXServiceMesh и Get-HCXInterconnectStatus были существенно доработаны, чтобы уметь исправлять ситуацию при различных ошибках. Также свойство DestinationNetworkValue теперь отображается корректно.
Как обычно, обновление модулей PowerCLI происходит командой:
Недавно на сайте проекта VMware Labs обновилась одна из самых полезных утилит для администраторов хранилищ VMware vSphere – IOBlazer. Она позволяет сгенерировать нагрузку на хранилища с любых платформ - Linux, Windows и Mac OS, при этом администратор может задавать паттерн нагрузки с высокой степенью кастомизации, что очень важно для реального тестирования подсистемы хранения для виртуальных машин.
Недавно мы писали про интересную штуку - утилиту Machine Learning on VMware Cloud Foundation, которая предоставляет инженерам по работе с данными инструменты в области Data Science в рамках виртуальной инфраструктуры. К сожалению, она пока не поддерживает использование GPU хостов, а работает только с CPU. Но заслуживает внимание сам факт такого решения - VMware начинает плотно прорабатывать тему машинного обучения.
Еще один элемент этой концепции - выпущенный на днях документ "Learning Guide – GPUs for Machine Learning on vSphere". В нем VMware рассказывает о том, как правильно строить системы, заточенные под алгоритмы машинного обучения, на платформе VMware vSphere.
Документ позволит архитекторам ИТ-инфраструктур и командам DevOps ответить на следующие вопросы:
Зачем нужны серверы с GPU для задач machine learning (ML) на платформах high performance computing (HPC).
Как именно используется модуль GPU.
Как на платформе vSphere строить ML-системы.
Как транслировать модуль GPU в рабочую нагрузку ML в виртуальной машине.
Как наладить взаимодействие между командой data scientists и администраторов виртуальной инфраструктуры.
Задачи машинного обучения с использованием GPU можно решать тремя способами:
Эти способы реализуют соответствующие технологии:
Об остальном читайте в интереснейшем документе на 43 страницах. В конце вайтпэйпера приведена огромная коллекция полезных ссылок на документы и статьи по практическому применению задач машинного обучения в виртуальных средах.
На сайте проекта VMware Labs появилась очередная интересная утилита - виртуальный модуль vSAN Performance Monitor, предназначенный для мониторинга метрик в среде отказоустойчивых кластеров VMware vSAN и их визуализации.
С помощью vSAN Performance Monitor администратор может на регулярной основе собирать метрики производительности в кластерах vSAN, которые потом визуализуются на уже преднастроенных дэшбордах, встроенных в продукт.
С помощью этих данных администраторы смогут диагностировать проблемы, а также распознавать текущие и намечающиеся узкие места в инфраструктуре, которые могут оказаться причиной низкой производительности.
Напомним, что 5 лет назад была выпущена похожая утилита - vSAN Observer, ну а создатели vSAN Performance Monitor открыто пишут, что при разработке вдохновлялись именно ей.
Само средство поставляется в виде виртуального модуля (Virtual Appliance), который реализует 3 основных компонента:
Коллектор Telegraf - это агент, который собирает метрики в кластере и сохраняет их в базе данных InfluxDB.
InfluxDB - собственно, сама база данных, хранящая метрики.
Grafana - это фреймворк, который используется для визуализации метрик из базы.
После развертывания администратору лишь нужно указать простые настройки и подключить коллектор к одному или нескольким целевым кластерам и стартовать сервис. После этого данные будут собираться на периодической основе и могут быть визуализованы в любой момент.
В качестве платформы и целевой машины для vSAN Performance Monitor поддерживаются vSphere 6.0 и VM hardware 11 (или более поздние). Для работы утилиты вам потребуется включить службу Virtual SAN Performance Service (о том, как это сделать, написано вот тут).
Скачать vSAN Performance Monitor можно по этой ссылке.
Вчера мы писали о том, что в перед предстоящим VMworld 2019 компания VMware рассказала о новых возможностях решения для организации отказоустойчивых кластеров хранилищ VMware vSAN 6.7 Update 3. Одновременно с этим была анонсирована и новая версия главной платформы виртуализации VMware vSphere 6.7 Update 3.
Напомним, что прошлая версия - vSphere 6.7 Update 2 - вышла весной этого года. Давайте посмотрим, что нового будет в vSphere 6.7 U3:
1. Поддержка нескольких vGPU (от NVIDIA) для одной виртуальной машины.
Теперь vSphere поддерживает несколько устройств NVIDIA GRID virtual GPU (vGPU), привязанных к одной виртуальной машине. Это, прежде всего, даст возможность увеличения вычислительных мощностей для тяжелых нагрузок, предъявляющих высокие требования к расчетам графического процессора (например, задачи машинного обучения).
2. Поддержка AMD EPYC Generation 2.
Новый релиз vSphere будет полностью совместим с поколением процессоров AMD EPYC. VMware и AMD работают в тесном сотрудничестве в целях поддержки самых последних нововведений в плане безопасности и производительности, заявленных в последних моделях данной линейки CPU.
3. Возможность изменить PNID для vCenter.
Идентификатор PNID (Primary Network IDentifier) сервера vCenter Server - это его сетевое имя (оно же FQDN), которое задается на этапе установки. Теперь есть возможность изменить его прямо в интерфейсе:
4. Поддержка Dynamic DNS (DDNS).
Dynamic DNS - это механизм обновления записей DNS-серверов новыми данными при изменении IP-адресов хостов. Ранее при использовании динамических IP для vCenter Server appliance (VCSA), в случае, если адрес менялся, приходилось вручную обновлять DNS-записи (собственно, поэтому никто и не использовал динамические IP). Теперь же с поддержкой DDNS этот процесс автоматизирован.
5. Улучшения поддержки драйверов.
Для сетевого драйвера VMXNET3 версии 4 были добавлены следующие возможности:
Guest encapsulation offload and UDP (расчет контрольных сумм)
Поддержка ESP RSS для стека Enhanced Networking Stack (ENS)
Также было обновлено множество драйверов, например, в драйвере ixgben появились функции queue pairing для оптимизации производительности CPU, а в драйвере bnxtnet добавилась поддержка адаптеров Broadcom 100 GbE и потоков multi-RSS.
Вот полный список обновленных драйверов:
VMware nvme
Microchip smarpqi
Marvell qlnativefc
Broadcom lpfc/brcmfcoe
Broadcom lsi_msgpt2
Broadcom lsi_msgpt35
Broadcom lsi_msgpt3
Broadcom lsi_mr3
Intel i40en
Intel ixgben
Cisco nenic
Broadcom bnxtnet
Скорее всего, новая версия VMware vSphere 6.7 Update 3 будет доступна для скачивания либо во время VMworld 2019, либо через несколько дней после его завершения. Следите за нашими обновлениями.
В прошлом мы много писали о стенсилах Visio для различных продуктов VMware (а также от других вендоров, например, Veeam Stencils). Между тем, пользоваться Visio не всем удобно - кто-то привык работать на Mac OS, где нет Microsoft Visio, кому-то не хочется покупать этот инструмент ради простеньких диаграмм и т.п.
Потому я думаю, что многим будет полезно узнать о проекте draw.io, который бесплатно позволяет рисовать схемы и диаграммы средствами онлайн-утилиты с использованием стенсилов VMware, Veeam и других. Для начала работы загрузите, например, стенсилы VMware с помощью меню Import:
После импорта можно сразу начать рисовать диаграммы:
После составления диаграммы или схемы, ее можно экспортировать в формат картинки или PDF, а также в файл VSDX (это пока в состоянии beta).
Напомним, что сами стенсилы можно скачать по этим ссылкам:
Безусловно, онлайн-редактор draw.io не заменяет полноценного Visio, но для рисования простых диаграмм и визуализации рабочих процессов его вполне хватит. Также у этого решения развиваются и офлайн-клиенты, которые можно скачать по этим ссылкам:
В апреле мы писали о релизе облачной архитектуры VMware Cloud Foundation 3.7, в которую входит большинство основных продуктов для развертывания, исполнения, мониторинга и поддержки виртуальной инфраструктуры в онпремизном датацентре.
В конце июля компания VMware выпустила обновление этой архитектуры - Cloud Foundation 3.8. Теперь в состав комплекса решений входят следующие компоненты:
Давайте посмотрим, что там появилось нового:
1. Первый релиз публичного API.
Теперь облачной инфраструктурой можно управлять через публично доступный API, который включает в себя функции для создания, удаления и получения свойств объектов домены рабочей нагрузки (Workload Domains), кластеры, сетевые пулы и хосты. Данный API пока очень простой, но будет дорабатываться в дальнейшем.
2. Упрощение управления жизненным циклом.
Теперь вся архитектура поддерживает автоматическое обновление продуктов семейства Realize с помощью продукта vRealize Suite Lifecycle Manager (vRSLCM). Можно обновлять vRealize Log Insight, vRealize Operations Manager и vRealize Automation. Также автоматическое обновление доступно и для решения VMware NSX-T.
3. Поддержка Cloud Foundation на платформе VxRail.
Начиная с прошлого релиза, все компоненты vCF можно развернуть на аппаратной платформе Dell EMC VxRail. Но теперь эта поддержка позволяет использовать самый последний набор решений виртуального датацентра, включая продукт NSX-T в последней версии архитектуры.
Также консоль SDDC Manager теперь поддерживает управление сертификатами для VxRail Manager. Помимо этого, VxRail Manager теперь интегрирован с решением Log Insight таким образом, что он предоставляет автоматизацию управления логами и мониторинг для всей инфраструктуры.
4. Улучшения масштабируемости.
Теперь vCF поддерживает расширение кластера vRealize Operations Manager в консоли SDDC Manager для случаев, когда пользователям нужно промасштабировать кластер и добавить новые узлы.
5. Улучшения SSO.
Для обеспечения лучшего взаимодействия между доменами управления (Management Domains) и доменами рабочей нагрузки (Workload Domains), архитектура Cloud Foundation теперь может объединять домены SSO (а точнее их контроллеры PSC) для двух или более экземпляров Cloud Foundation.
Более подробно узнать об архитектуре VMware Cloud Foundation 3.8 можно по этой ссылке. Release Notes доступны тут (а вот тут - для платформы VxRail).
Как многие из вас знают, с 25 по 29 августа в Сан-Франциско пройдет главная конференция года в области виртуализации - VMworld 2019. На конференции будут представлены сотни докладов, практических семинаров и лабораторных работ, поэтому планировать свое время нужно заранее.
Напомним, что конференцию можно посетить не только лично, но и посмотреть онлайн. Чтобы найти подходящую вам сессию, нужно воспользоваться вот этим порталом поиска. На данный момент там представлено 1032 материала:
Extreme Performance Series - это маст си о производительности платформы VMware vSphere, где нам покажут новые максимумы платформы и достижения в сфере высокой производительности.
На прошлой неделе мы писали об организации среды управления на базе vCenter Hybrid Linked Mode для гибридной виртуальной инфраструктуры, объединяющей ресурсы частного и публичного облаков. Сегодня мы поговорим еще об одной полезной вещи - библиотеке контента Content Library, в которой можно хранить шаблоны виртуальных машин (VM Templates), готовые виртуальные устройства (Virtual Appliances) в формате OVF/OVA, а также другие объекты (например, ISO-образы).
VMware vSphere Content Library позволяет подписать датацентры на обновления главного датацентра (который представляется как издатель/publisher), где можно создать шаблон виртуальной машины, а на уровне подчиненного датацентра (подписчик/subscriber) администраторы видят содержимое библиотеки и развертывают машины из него.
Такая же ситуация и с облачной и гибридной средой - Content Library очень просто и быстро позволяет распространять контент по сети датацентров.
Так же, как и в онпремизной инфраструктуре, в облаке VMware vCloud on AWS вы можете подписаться на обновления существующей Content Library. Для этого в vSphere Client перейдите в Menu > Content Libraries:
Нажмите плюсик для создания новой библиотеки:
Там нужно задать имя библиотеки и указать адрес облачного сервера SDDC vCenter Server (можно указать и онпремизный vCenter, если у вас библиотека на нем):
Далее указываем Subscription URL вашей библиотеки:
Можно сделать и локальную библиотеку, чтобы пользоваться ее ресурсами только в рамках облачной среды этого vCenter.
Дальше выбираем хранилище, где будет находиться контент:
Ну и после создания библиотека появится в списке:
Когда вы кликните на библиотеку, вы увидите разделение на шаблоны виртуальных машин, готовые виртуальные модули OVF/OVA и другой контент, такой как ISO-образы:
Далее можно выбрать, например, шаблон ВМ, нажать на него правой кнопкой и выбрать пункт создания новой ВМ из этого шаблона (New VM from This Template...):
Мы часто пишем об облачной платформе VMware vCloud on AWS (VMConAWS), которая позволяет разместить виртуальные машины на базе VMware vSphere в облаке Amazon AWS, а также построить гибридную среду, сочетающую в себе онпремизные и облачные ресурсы виртуальной инфраструктуры.
Сегодня мы поговорим об основном инструменте VMC, который позволяет управлять гибридной облачной средой. Сначала отметим, что управление такой структурой основывается на механизме Linked Mode, который объединяет серверы vCenter и позволяет использовать единое пространство объектов в географически распределенных датацентрах. Сейчас он называется Enhanced Linked Mode или Embedded Linked Mode (когда Platform Services Controller и vCenter Server Appliance находятся вместе на одном сервере).
Если вы разворачиваете Linked Mode на собственной инфраструктуре, то все серверы vCenter должны быть в одном домене SSO и иметь одну и ту же версию (включая номер билда). Когда же вы используете общий режим vCenter в гибридной среде (Hybrid Linked Mode), то ситуация, когда в облаке развернута более новая версия vCenter, считается нормальной.
Есть 2 способа использовать гибридный режим управления vCenter. Первый - это развернуть виртуальный модуль (virtual appliance) Cloud Gateway в своей инфраструктуре и соединить его с облачной инфраструктурой SDDC. Второй - это зайти с помощью vSphere Client на облачный SDDC и управлять объединенными ресурсами частного и публичного облака оттуда.
Во втором случае вы можете подключить только один домен онпремизной инфраструктуры, поэтому если у вас сложная доменная инфраструктура, то необходимо использовать первый метод.
Чтобы начать работу по созданию единой управляющей среды гибридного облака, нужно скачать установщик Cloud Gateway installer. Для этого надо зайти в консоль VMware Cloud on AWS и перейти на вкладку Tools. Там можно скачать этот виртуальный модуль:
Скачиваем ISO-образ Cloud Gateway и монтируем его к вашей рабочей станции. Запускаем его из папки /ui-installer и проходим по шагам мастера. На одном из них задаем параметры сервера онпремизного vCenter, где будет установлен шлюз:
В процессе установки вас попросят указать пароль root, целевой датастор, конфигурацию сети, NTP и SSO, также будет возможность присоединить шлюз к домену Active Directory.
Далее нужно переходить ко второму этапу - настройке гибридного режима Hybrid Linked Mode. Не забудьте свериться с требованиями к этому режиму в документации.
Далее нужно будет указать IP-адрес облачного сервера vCenter и параметры учетной записи cloudadmin@vmc.local.
Эту информацию можно получить в консоли VMware Cloud on AWS, выбрав ваш SDDC, затем Settings и развернуть поле Default vCenter User Account:
В качестве Identity Source нужно указать ваш онпремизный домен AD, для которого вы хотите настроить доступ.
После этого все будет настроено, и вы можете начинать управлять своей гибридной инфраструктурой через vSphere Client:
На прошлой неделе мы писали о выпуске мобильного клиента для управления виртуальной инфраструктурой VMware vSphere - Mobile Client версии 1.1.
А на днях компания VMware на сайте проекта Labs уже выложила его обновление - vSphere Mobile Client 1.2. Давайте посмотрим, что там нового:
Улучшения inventory - возможность добавить ВМ в закладки, после чего можно быстро перейти к ней из верхней панели в заголовке.
Дэшборд vCenter теперь агрегирует хосты и виртуальные машины.
Свайп карточки ВМ теперь показывает скриншот, по клику на который отображается большая картинка.
Множество исправлений ошибок.
Скачать обновленный vSphere Mobile Client 1.2 можно по этим ссылкам:
Android - до того, как устанавливать клиент, вам надо присоединиться к этой группе Google Groups, члены которой принимают участие в альфа-тестировании.
Чтобы получать пуш-уведомления на ваши устройства, нужно будет поднять vSphere Mobile Client Notification Service в виде контейнера Docker. О том, как это сделать написано тут, а скачать сам контейнер можно на странице vSphere Mobile Client.
Многи администраторы VMware vSphere, особенно в крупных инфраструктурах, развертывают механизм VMware vCenter HA, обеспечивающий отказоустойчивость сервера VMware vCenter (а точнее виртуальной машины vCenter или vCenter Server Appliance, vCSA). Все понимают, что vCenter / vCSA - это важнейшая часть виртуальной инфраструктуры, ведь без нее не работают такие критичные сервисы, как Site Recovery Manager, NSX и Horizon View.
Функции vCenter HA появились еще в VMware vSphere 6.5, но в vSphere 6.7 Update 1 они были существенно доработаны, а сам процесс обновления и апгрейдов vCenter упрощен. При этом управление механизмом vCenter HA полностью перешло в vSphere Client в рамках единого рабочего процесса (раньше были 2 воркфлоу - Basic и Advanced).
Давайте посмотрим, какие пути апгрейда и обновления существуют для конфигурации vCenter HA. Для начала напомним, как это выглядит:
Две машины с vCenter (активный узел и его клон - пассивный узел), а также компонент Witness образуют собой кластер, где Witness защищает от сценария Split Brain в среде vCenter HA (не путайте это с обычным vSphere HA). В случае отказа основного узла, его функции берет на себя резервный, что существенно быстрее по сравнению с восстановлением vCenter средствами стандартного HA (перезапуск на другом сервере). Это в итоге отражается на меньшем времени RTO для таких критичных сервисов, как SRM и NSX, в случае сбоев.
Перед обновлением помните, что для vCenter HA не поддерживается создание снапшотов, а значит нужно обязательно сделать File-Based Backup основного сервера vCenter перед обновлением.
Если у вас VMware vSphere 6.5, то при обновлении вы можете не разбивать кластер vCenter HA, а просто скачать ISO-образ с обновлениями (через VMware Patch Portal), либо ничего не скачивать и сразу инициировать процесс обновления из командной строки, если у вас есть доступ в интернет из компонентов кластера.
Делается все это так:
Сначала кластер vCenter HA надо перевести в режим обслуживания (maintenance mode), что не прервет репликацию, но предотвратит автоматический запуск процесса восстановления (failover).
Затем заходим на компонент Witness по SSH и запускаем его обновление из командной строки. Если у вас есть доступ в интернет на этом экземпляре vCenter, то делается это простой командой:
software-packages install --url --acceptEulas
Если же вы скачали ISO-образ с обновлениями, то делается это следующей командой:
software-packages install --iso --acceptEulas
Далее заходим на пассивный узел vCenter и там делаем то же самое.
Инициируем вручную процесс восстановления vCenter на пассивный узел (failover).
Обновляем активный узел vCenter.
Возвращаем конфигурацию в исходное состояние (failback).
Отключаем режим обслуживания (maintenance mode).
Если же у вас vCenter 6.7, то опция обновления у вас одна - отключение и удаление конфигурации HA, после чего происходит накат обновления на активном узле и повторное развертывание HA-конфигурации (такая же опция доступна и для vCenter 6.5). Этот рабочий процесс обусловлен изменениями в схеме базы данных, которые происходят в vCenter 6.7.
Начиная с vSphere 6.7 Update 1, установщик vCenter Server Upgrade installer может автоматически обнаружить присутствие кластера vCenter HA:
Далее в процессе обновления он сохранит его конфигурацию, обновит активный узел vCenter, а потом развернет его реплики для пассивного узла и узла Witness.
Надо понимать, что в процессе обновления машины с пассивным узлом и Witness будут удалены, поэтому не забудьте сделать бэкап. И сам процесс лучше проводить в ручном режиме, а не автоматическом, чтобы иметь больший контроль над получающейся итоговой конфигурацией.
Таги: VMware, vCenter, HA, vSphere, Update, Upgrade
Некоторые пользователи сталкиваются с проблемой при обновлении сервера VMware vCenter Server Appliance (vCSA). После накатывания апдейта на vCSA (в частности, здесь пишут про билд 6.5.0.30100) администратор идет по адресу:
https://<vCenter_FQDN>:5480
И видит, что страница не открывается, браузер не находит веб-сервер.
Это происходит потому, что иногда после обновления vCSA не поднимается служба vami-lighttp, которая отвечает за веб-интерфейс VAMI (Virtual Appliance Management Infrastructure). Нужно пойти в консоль vCSA и там выполнить следующую команду для вывода статуса этой службы:
ps -ef | grep vami-lighttp
Если вы увидите, что данный процесс лежит, то есть его нет в списке запущенных, то можно запустить его следующей командой:
/etc/init.d/vami-lighttp start
После этого VAMI должен начать работать. Также у vCSA есть загадочная зависимость от протокола IPv6, которая описана здесь.
Ну и посмотрите нашу статью, в которой описывается ситуация, когда страница VAMI на vCSA открывается, но при вводе учетных данных выводится сообщение "Unable to login".
Эта платформа предоставляет инженерам по работе с данными следующие возможности в области Data Science в рамках виртуальной инфраструктуры:
Виртуальное окружение на основе облака VMware Cloud Foundation (VCF) и платформы Kubernetes.
На данный момент для вычислений поддерживается только CPU (но модули GPU будут поддерживаться в будущем).
Платформа построена на базе фреймворков Open Source Kubeflow и Horovod.
Также в составе идет коллекция обучающих примеров (Notebooks) и библиотек, которые помогают понять выполнение следующих задач:
Data collection and cleaning (получение данных из различных источников и описание семантики данных с использованием метаданных).
Data cleansing and transformation (приведение собранных данных в порядок и их трансформация из сырого формата в структурированный, который больше подходит для процессинга).
Model training (разработка предиктивных и оптимизационных моделей машинного обучения).
Model serving (развертывание модели для запуска в реальном окружении, где могут обслуживаться онлайн-запросы).
Для использования движка vMLP вам потребуется развернутая инфраструктура VMware Cloud Foundation 3.8.
В комплекте с платформой идет документация. Скачать весь пакет можно по этой ссылке.
Вчера мы писали об очередной новинке на VMware Labs, мобильном клиенте vSphere Mobile Client для iOS и Android, а сегодня расскажем еще об одной утилите - Virtual Machine Compute Optimizer. Это средство представляет собой PowerShell-сценарий для модуля PowerCLI VMware.VimAutomation.Core, который собирает информацию о хостах ESXi и виртуальных машинах в вашем виртуальном окружении и выдает отчет о том, правильно ли они сконфигурированы с точки зрения процессоров и памяти.
Для этого в отчете есть колонка VMCPUsOptimized, которая принимает значения Yes или No.
Далее также идут колонки, где показаны оптимальные количества сокетов и ядер для виртуальных машин, которые было бы неплохо сделать для текущей конфигурации (OptimalSockets и OptimalCores). Текущая конфигурация также представлена в колонках VMNumSockets и VMCoresPerSocket.
Назначения колонок представлены на картинке ниже:
Надо понимать, что VMCO анализирует вашу инфраструктуру только на базе рекомендаций для оптимальной конфигурации виртуальных машин без учета реальной нагрузки, которая исполняется внутри. Для такой задачи нужно средство для сайзинга посерьезнее - например, VMware vRealize Operations Manager.
Скрипт Virtual Machine Compute Optimizer можно запускать как минимум под аккаунтом с правами на чтение инфраструктуры vCenter. Скачать его по этой ссылке.
Еще очень давно, 8 лет назад, компания VMware развивала мобильный клиент (см. также тут) для управления инфраструктурой VMware vSphere, но забросила это дело на некоторое время.
И вот совсем недавно на сайте проекта VMware Labs появилось средство vSphere Mobile Client 1.1. Это очередной подход VMware к управлению виртуальной средой через мобильные приложения для iOS и Android.
Само собой, vSphere Mobile Client предоставляет лишь малую часть функций полноценного клиента (но для мобильных устройств это и не нужно), вот основные из них:
Просмотр информации и виртуальных машинах - просмотр статуса ВМ (включено/выключено), использования ресурсов и конфигурации машин.
Управление ВМ - операции с питанием (в том числе, перезагрузка). Возможность найти виртуальную машину с помощью поиска. Если вы свайпните влево карточку с виртуальной машиной, то получите скриншот ее консоли, который можно сохранить.
Мониторинг задач - можно "подписаться" на любую запущенную задачу и получать нотификации на телефон о том, когда она завершится. При этом неважно, что ваш девайс находится в неактивном режиме или в данный момент вы работаете с другим приложением.
Графики производительности - можно отслеживать использование ресурсов виртуальными машинами в реальном времени, либо в разрезе дня, недели, месяца или года назад. Счетчики включают в себя метрики CPU, памяти, хранилищ и сети. Также на дэшборде можно посмотреть общее использование ресурсов vCenter.
Ссылки на загрузку vSphere Mobile Client:
Android - до того, как устанавливать клиент, вам надо присоединиться к этой группе Google Groups, члены которой принимают участие в альфа-тестировании.
Чтобы получать пуш-уведомления на ваши устройства, нужно будет поднять vSphere Mobile Client Notification Service в виде контейнера Docker. О том, как это сделать написано тут, а скачать сам контейнер можно на странице vSphere Mobile Client.
Многие из администраторов VMware vSphere знают про механизм Storage I/O Control (SIOC) в платформе VMware vSphere (см. также наш пост здесь). Он позволяет приоритезировать ввод-вывод для виртуальных машин в рамках хоста, а также обмен данными хостов ESXi с хранилищами, к которым они подключены.
Сегодня мы поговорим о SIOC версии 2 и о том, как он взаимодействует с политиками Storage Policy Based Management (SPBM). Начать надо с того, что SIOC v2 полностью основан на политиках SPBM, а точнее является их частью. Он позволяет контролировать поток ввода-вывода на уровне виртуальных машин.
SIOC первой версии работает только с томами VMFS и NFS, тома VVol и RDM пока не поддерживаются. Он доступен только на уровне датасторов для регулирования потребления его ресурсов со стороны ВМ, настраиваемого на базе шар (shares). Там можно настроить SIOC на базе ограничения от пиковой пропускной способности (throughput) или заданного значения задержки (latency):
На базе выделенных shares виртуальным машинам, механизм SIOC распределит пропускную способность конкретного хранилища между ними. Их можно изменять в любой момент, перераспределяя ресурсы, а также выставлять нужные лимиты по IOPS:
Надо отметить, что SIOC v1 начинает работать только тогда, когда у датастора есть затык по производительности, и он не справляется с обработкой всех операций ввода-вывода.
Если же мы посмотрим на SIOC v2, который появился в VMware vSphere 6.5 в дополнение к первой версии, то увидим, что теперь это часть SPBM, и выделение ресурсов работает на уровне виртуальных машин, а не датасторов. SIOC v2 использует механизм vSphere APIs for I/O Filtering (VAIO), который получает прямой доступ к потоку ввода-вывода конкретной ВМ, вне зависимости от того, на каком хранилище она находится.
Таким образом, вы можете использовать SIOC v2 для регулирования потребления машиной ресурсов хранилища в любой момент, а не только в ситуации недостатка ресурсов.
Поэтому важно понимать, что SIOC v1 и SIOC v2 можно использовать одновременно, так как они касаются разных аспектов обработки потока ввода-вывода от виртуальных машин к хранилищам и обратно.
SIOC v2 включается в разделе политик SPBM, в секции Host-based rules:
На вкладке Storage I/O Control можно выбрать предопределенный шаблон выделения ресурсов I/O, либо кастомно задать его:
Для выбранной политики можно установить кастомные значения limit, reservation и shares. Если говорить о предопределенных шаблонах, то вот так они выглядят для варианта Low:
Так для Normal:
А так для High:
Если выберите вариант Custom, то дефолтно там будут такие значения:
Лимит можно задать, например, для тестовых машин, где ведется разработка, резервирование - когда вы точно знаете, какое минимальное число IOPS нужно приложению для работы, а shares можете регулировать долями от 1000. Например, если у вас 5 машин, то вы можете распределить shares как 300, 200, 100, 100 и 100. Это значит, что первая машина будет выжимать в три раза больше IOPS, чем последняя.
Еще один плюс такого назначения параметров SIOC на уровне ВМ - это возможность определить политики для отдельных дисков VMDK, на которых может происходить работа с данными разной степени интенсивности:
После того, как вы настроили политики SIOC v2, вы можете увидеть все текущие назначения в разделе Monitor -> Resource Allocation -> Storage:
Мы часто пишем о томах VVols (Virtual Volumes), которые позволяют вынести часть нагрузки по обработке операций с хранилищами на сторону аппаратных устройств (они, конечно же, должны поддерживать эту технологию), что дает пользователям преимущества по сравнению с VMFS. В инфраструктуре VVols массив сам определяет, каким образом решать задачи доступа и организации работы с данными для виртуальных машин, выделяя для их объектов (виртуальные диски и прочее) отдельные логические тома (VVols).
Один из известных производителей, поддерживающих технологию VVols - это компания Pure Storage. Недавно Cody Hosterman написал статью о том, как подключить тома VVols в VMware vSphere через PowerCLI для хранилищ Pure Storage. Коди развивает свой модуль PowerShell, который называется PureStorage.FlashArray.VMware.
Давайте посмотрим, как он работает. Сначала можно почитать о доступных опциях командлета Mount-PfaVvolDatastore, с помощью которого можно сделать монтирование датастора VVol:
Командлет может делать следующее:
Проверяет, презентован ли protocol endpoint (PE) указанного массива кластеру. Если нет, то с его помощью можно сделать это.
Ресканирует кластер, чтобы убедиться, что PE виден хостам.
Монтирует VVol в кластере.
Возвращает датастор хранилищу.
Пример 1 - имеется прямой доступ к массиву
Соединяемся с vCenter и создаем соединение с FlashArray:
Значит тут мы полагаем, что администратор хранилищ уже настроил PE, и вам нужно только смонтировать том VVol:
Так как датастор VVol ранее не монтировался, нельзя просто создать array connection (нет доступа к массиву). В этом случае подойдет командлет Get-VasaStorageArray:
Передав в командлет монтирования массив FA-m50, имя кластера и имя датастора, можно смонтировать том VVol:
Не так давно мы писали о новых возможностях последней версии платформы виртуализации VMware vSphere 6.7 Update 2. Одним из нововведений стал улучшенный интерфейс управления плагинами (Plugin Management UI), который дает пользователю полный контроль над процессами обновления и развертывания плагинов к vSphere.
Если еще в Update 1 при установке нового плагина или обновлении старого, в случае неудачи процесс просто завершался, и приходилось смотреть в файл журнала, то теперь для этого есть графическое представление с выводом информации о возникших проблемах (например, несовместимость с новой версией платформы).
В подразделе Client Plug-ins раздела Administrator теперь приведены все клиентские зарегистрированные плагины на любом из серверов vCenter в вашем окружении. Также у этих плагинов есть статусы: In Progress, Deployed, Failed или Incompatible.
Статусы Failed и Incompatible являются кликабельными - при нажатии на них всплывет подсказка с возможной причиной возникновения подобных ошибок или причины несовместимости (при возможности будет также приведен участок лога):
В процессе инсталляции плагин проходит через несколько фаз, которые отслеживаются сервером vCenter, также их можно получать через TaskManager API (его могут использовать и сторонние разработчики). Выполняемые задачи отображаются на сервере vCenter в 3 разделах:
Панель Recent Tasks в нижней части клиента
Консоль в разделе задач (Task Console)
Просмотр представления Tasks для выбранного объекта vCenter Server
Задачи создаются и отслеживаются на сервере vCenter, к которому в данный момент подключен vSphere Client. Если же виртуальная среда работает в режиме федерации Enhanced Linked Mode, то задачи по развертыванию плагина создаются на всех подключенных серверах vCenter. Поэтому любой экземпляр vSphere Client будет видеть эти задачи.
Как происходит работа с плагинами
При логине пользователя в vSphere Client, все плагины vCenter загружаются в кэшированную папку самого клиента на сервере vCenter. Для отслеживания этого процесса создается задача "Download plug-in". Если загрузка плагина прошла успешно, то он становится доступным для развертывания, что видно в консоли задач. И это значит, что он был загружен в кэшированную папку.
Следующая фаза - это задача "Deploy plug-in", которая стартует следующей. Если она завершается успешно, это значит, что плагин установлен и доступен для использования со стороны vSphere Client. Кстати, если задача Download plug-in прошла с ошибкой, то и задача Deploy plug-in будет пропущена.
Ошибки плагинов при развертывании теперь детально описаны в консоли:
Также иногда к ошибке прилагается лог развертывания, например, в случае, когда их вызвало стороннее программное обеспечение, отдающее некоторый лог ошибки.
В случае апгрейда плагина этот процесс представляется набором из трех задач: "Download plug-in", "Undeploy plug-in" и "Deploy plug-in". После этого в vSphere Client появляется глобальная нотификация о новой версии развернутого плагина и с просьбой сделать рефреш в браузере, чтобы плагин начал работать.
Один сервер vCenter может работать только с одной версией плагина, но в архитектурах Enhanced Linked Mode и Hybrid Linked Mode может быть несколько серверов vCenter, каждый из которых может содержать свою версию плагина.
В этом случае vSphere Client обрабатывает плагины двумя способами:
Local plug-in architecture - в этом случае оперирование происходит с самой новой версией плагина, обнаруженной на всех доступных серверах vCenter. При этом все остальные версии плагина игнорируются. Если обнаруживается более новая версия плагина на одном из серверов vCenter - происходит ее апгрейд.
Remote plug-in architecture - она появилась в vSphere 6.7 Update 1. В этом случае происходит поддержка своей версии плагина на уровне того сервера vCenter, с которым происходит оперирование со стороны vSphere Client. Такое поведение используется, например, в среде Hybrid Linked Mode, где версии плагинов и серверов vCenter могут отличаться очень значительно. В этом случае все версии плагина скачиваются с соответствующих экземпляров vCenter и работа со стороны vSphere Client происходит с каждой версией как с независимым плагином.
Ну и напоследок приведем статусы, которые могут возникать при развертывании и апгрейде плагинов:
In progress
Плагин находится в стадии развертывания.
Deployed
Плагин установлен и доступен для использования через интерфейс vSphere Client.
Failed
Показывается при невозможности скачать или установить плагин:
Download error
Установка из незащищенного места - используется http вместо https.
Невозможно получить URL плагина.
vSphere Client не авторизован для скачивания плагина.
Packaging error
Поврежден zip-пакет плагина.
Отсутствует файл манифеста.
Отсутствует папка plugins.
Отсутствуют необходимые бандлы в плагине.
Deployment error
Ошибка связей (Dependency error) при развертывании плагина на vSphere Client.
На днях компания VMware выпустила третий пакет обновления для предыдущего поколения своей главной платформы виртуализации - VMware vSphere 6.5 Update 3. Напомним, что Update 2 вышел в мае прошлого года, так что давно было уже пора выпускать апдейт, так как версия 6.5 по-прежнему широко используется, особенно в крупных предприятиях.
Давайте посмотрим, что нового в vSphere 6.5 U3.
Новые функции vCenter 6.5 Update 3:
События о добавлении, удалении и модификации пользовательских ролей содержат информацию о пользователе, который производит изменения.
Улучшения возможностей аудита в компоненте VMware vCenter Single Sign-On - теперь появились события для следующих операций: управление пользователями, логин, создание групп, изменение источника идентификации, управление политиками. Доступна эта фича только для виртуального модуля vCSA с интегрированным Platform Services Controller. Поддерживаемые источники идентификации: vsphere.local, Integrated Windows Authentication (IWA) и Active Directory over LDAP.
Поддержка новых внешних баз данных - добавлена поддержка Microsoft SQL Server 2014 SP3.
Драйвер ixgben добавляет функцию queue pairing для оптимизации эффективности CPU.
С помощью ESXi 6.5 Update 3 вы можете отслеживать использование лицензий и обновлять топологию коммутаторов. Также улучшения можно увидеть в Developer Center клиента vSphere Client.
Поддержка устаревших серверов AMD Zen 2.
Множество обновлений драйверов устройств: lsi-msgpt2, lsi-msgpt35, lsi-mr3, lpfc/brcmfcoe, qlnativefc, smartpqi, nvme, nenic, ixgben, i40en и bnxtnet.
Поддержка Windows Server Failover Clustering и Windows Server 2019.
Добавлено свойство com.vmware.etherswitch.ipfixbehavior в распределенные виртуальные коммутаторы, чтобы позволить пользователям выбирать способ трекинга входящего и исходящего трафика. Значение 1 включает сэмплирование для входящего и исходящего трафика, значение 0 включает его только для исходящего (значение по умолчанию).
Если вы ожидали среди возможностей чего-то действительно нового - увы, этого не бывает. VMware надо развивать ветку vSphere 6.7 и следующие версии платформы. Скачать VMware vSphere 6.5 Update 3 можно по этой ссылке.
Какие еще продукты VMware были обновлены параллельно с этим релизом:
Многие администраторы платформы VMware vSphere очень часто интересуются вопросом замены сертификатов для серверов ESXi в целях обеспечения безопасности. Как правило, это просто инструкции, которые не дают понимания - а зачем именно нужно менять эти сертификаты.
Недавно VMware выпустила интересную статью на тему сертификатов в vSphere и других продуктах, приведем ниже основные выдержки из нее.
1. Сертификаты - это вопрос доверия и шифрования.
При соединении с различными веб-консолями компонентов инфраструктуры VMware vSphere используется протокол HTTPS, где S означает "Secure". Инфраструктура SSL, а точнее ее последователь Transport Layer Security (TLS), использует известный в криптографии принцип открытого и закрытого ключей, который позволяет узлам, доверяющим друг другу безопасно обмениться информацией по шифрованному каналу.
TLS развивается по следующему пути:
Версия 1.0 имеет уязвимости, он небезопасен и больше не должен использоваться.
Версия 1.1 не имеет таких уязвимостей, как 1.0, но использует такие алгоритмы шифрования, как MD5 и SHA-1, которые больше не считаются безопасными.
Версия 1.2 добавляет шифрование AES, которое работает быстро и не использует небезопасные методы, сам же алгоритм использует SHA-256. На текущий момент это стандарт TLS.
Версия 1.3 не содержит слабых точек и добавляет возможности увеличения скорости соединения, этот стандарт скоро будет использоваться.
Если вы используете сертификаты vSphere, то независимо от того, какие они (самоподписанные или выданные центром сертификации) - общение между компонентами виртуальной инфраструктуры будет вестись посредством TLS с надежным шифрованием. Вопрос сертификатов тут - это всего лишь вопрос доверия: какому объекту, выпустившему сертификат, вы доверяете - это и есть Центр сертификации (он же Certificate Authority, CA).
Многие крупные компании, имеющие определенный вес (например, Microsoft) сами являются Центрами сертификации, а некоторые компании используют службы Microsoft Active Directory Certificate Services, чтобы встроить собственные CA в операционную систему и браузеры (импортируют корневые сертификаты), чтобы "научить" их доверять этим CA.
2. В VMware vSphere сертификаты используются повсеместно.
Как правило, они используются для трех целей:
Сертификаты серверов ESXi, которые выпускаются для управляющих интерфейсов на всех хост-серверах.
"Машинные" сертификаты SSL для защиты консолей, с которыми работает человек - веб-консоль vSphere Client, страница логина SSO или Platform Service Controllers (PSCs).
"Solution"-сертификаты, используемые для защиты коммуникаций со сторонними к платформе vSphere продуктам, таким как vRealize Operations Manager, vSphere Replication и другим.
Полный список компонентов, где vSphere использует сертификаты, приведен вот тут.
3. vSphere имеет собственный Центр сертификации.
Платформа vSphere из коробки поставляется с собственным CA, который используется для коммуникации между компонентами. Называется он VMware Certificate Authority (VMCA) и полностью поддерживается для vSphere как с внешним PSC, так и для vCenter Server Appliance (vCSA) со встроенным PSC.
Как только вы добавляете хост ESXi в окружение vCenter, то VMCA, работающий на уровне vCenter, выпускает новый сертификат на этот ESXi и добавляет его в хранилище сертификатов. Такая же штука происходит, когда вы настраиваете интеграцию, например, с решениями vRealize Operations Manager или VMware AppDefense.
Надо понимать, что CA от VMware - это всего лишь решение для защищенной коммуникации между серверами, которое поставляется из коробки. Ваше право - доверять этой модели или нет.
4. Есть 4 способа внедрить инфраструктуру сертификатов на платформе vSphere.
Вот они:
Использовать самоподписанные сертификаты VMCA. Вы можете просто скачать корневые сертификаты с веб-консоли vCenter, импортировать их в операционную систему клиентских машин. В этом случае при доступе к веб-консоли, например, vSphere Client у вас будет отображаться зеленый замочек.
VMCA можно сделать подчиненным или промежуточным (subordinate/ intermediate) центром сертификации, поставив его посередине между CA и конечными хостами, что даст дополнительный уровень сложности и повысит вероятность ошибки в настройке. VMware не рекомендует так делать.
Отключить VMCA и использовать собственные сертификаты для любых коммуникаций. Ваш ответственный за сертификаты должен нагенерировать запросы Certificate Signing Requests (CSR) для всех компонентов. Эти CSR-запросы вы отсылаете с CA, которому вы доверяете, получаете их подписанными, после чего устанавливаете их в ручном режиме. Это отнимает время и чревато ошибками.
Использовать гибридный подход - для хостов ESXi в их коммуникации с vCenter использовать самоподписанные VMCA сертификаты, а для веб-консолей vSphere Client и прочих использовать перевыпущенные сертификаты, которые надо установить на сервере vCenter и хостах, с которых будет управляться инфраструктура через браузер (тогда в нем появится зеленый замочек). Это самый рекомендуемый VMware вариант использования сертификатов.
5. Enterprise-сертификаты - тоже самоподписанные.
Подумайте - самоподписанными являются не только сертификаты VMCA, но и ваши корпоративные сертификаты. Если вы выпускаете эти сертификаты только на уровне своей компании, то у вас 2 точки потенциального недоверия - сторона, выпустившая сертификаты у вас в компании, а также, собственно, сам VMCA. Такая схема создает дополнительный уровень сложности администрирования, а также нарушения безопасности.
6. Не создавайте промежуточный Центр сертификации.
Если вы создаете intermediate CA (он же subordinate CA) для VMCA, превращая его в посредника, вы создаете потенциальную опасность для виртуальной инфраструктуры - если кто-то получает доступ к корпоративному центру сертификации и его парам ключей, то он может навыпускать любых сертификатов от имени VMCA и перехватывать потом любые коммуникации.
7. Можно изменять информацию для самоподписанных сертификатов CA.
С помощью утилиты Certificate Manager utility вы можете сгенерировать новый VMCA с необходимой информацией о вашей организации внутри него. Эта утилита перевыпустит все сертификаты и заменит их на всех хостах виртуальной инфраструктуры. Это хорошая опция для гибридной модели. Кстати, вы можете менять даты устаревания сертификатов, если дефолтные вас не устраивают.
8. Тестируйте инфраструктуру сертификатов перед внедрением.
Вы можете развернуть виртуальную инфраструктуру и провести все эксперименты с сертификатами в виртуальной среде, где вы можете использовать виртуальные (nested) серверы ESXi. Приятная штука в том, что вы можете создавать снапшоты виртуальных машин, а значит в случае чего - быстро откатитесь на рабочий вариант. Еще одна среда для экспериментов - это облачная инфраструктура VMware Hands-on Labs, где можно безопасно ставить любые эксперименты.
Делайте резервную копию вашего vCenter и PSC на уровне файлов через веб-консоль VAMI. Также утилитой Certificate Manager можно скопировать старый набор сертификатов перед развертыванием новых (но только один набор сертификатов, учитывайте это). Также эта процедура полностью поддерживается со стороны VMware Global Support Services.
10. Понимайте, зачем вы заморачиваетесь с заменой сертификатов.
Ответьте для себя на несколько вопросов:
Стоит ли иконка зеленого замочка в браузере всех этих заморочек?
Нужно ли всем видеть этот замочек или только команде администрирования vSphere?
Почему вы доверяете vCenter для управления всем в виртуальной инфраструктуре, но не доверяете VMCA?
В чем отличие самоподисанного сертификата вашего предприятия от самоподписанного сертификата VMCA?
Действительно ли комплаенс требует от вас кастомных CA-сертификатов?
Какова будет цена процедур по замене сертификатов в инфраструктуре vSphere во времени и деньгах?
Увеличивает или уменьшает риск итоговое решение и почему конкретно?
Как знают почти все администраторы платформы VMware vSphere, для кластеров VMware HA/DRS есть такой режим работы, как Enhanced vMotion Compatibility (EVC). Нужен он для того, чтобы настроить презентацию инструкций процессора (CPU) хостами ESXi так, чтобы они в рамках кластера соответствовали одному базовому уровню (то есть все функции процессоров приводятся к минимальному уровню с набором инструкций, которые гарантированно есть на всех хостах).
Ввели режим EVC еще очень давно, чтобы поддерживать кластеры VMware vSphere, где стоят хосты с процессорами разных поколений. Эта ситуация случается довольно часто, так как клиенты VMware строят, например, кластер из 8 хостов, а потом докупают еще 4 через год-два. Понятно, что процессоры уже получаются другие, что дает mixed-окружение, где по-прежнему надо перемещать машины между хостами средствами vMotion. И если набор презентуемых инструкций CPU будет разный - двигать машины между хостами будет проблематично.
EVC маскирует инструкции CPU, которые есть не на всех хостах, от гостевых ОС виртуальных машин средствами интерфейса CPUID, который можно назвать "API для CPU". В статье VMware KB 1005764 можно почитать о том, как в кластере EVC происходит работа с базовыми уровнями CPU, а также о том, какие режимы для каких процессоров используются.
Надо отметить, что согласно опросам VMware, режим кластера EVC используют более 80% пользователей:
В VMware vSphere 6.7 появились механизмы Cross-Cloud Cold и Hot Migration, которые позволяют переносить нагрузки в онлайн и офлайн режиме между облаками и онпремизной инфраструктурой.
Когда это происходит, виртуальной машине приходится перемещаться между хостами с разными наборами инструкций процессора. Поэтому, в связи с распространением распределенных облачных инфраструктур, в vSphere появилась технология Per-VM EVC, которая позволяет подготовить виртуальную машину к миграции на совершенно другое оборудование.
По умолчанию, при перемещении машины между кластерами она теряет свою конфигурацию EVC, но в конфигурации ВМ можно настроить необходимый базовый уровень EVC, чтобы он был привязан к машине и переезжал вместе с ней между кластерами:
Обратите внимание, что Per-VM EVC доступна только, начиная с vSphere 6.7 и версии виртуального железа Hardware Version 14. Эта конфигурация сохраняется в vmx-файле (потому и переезжает вместе с машиной) и выглядит следующим образом:
Некоторые пользователи не включают EVC, так как покупают унифицированное оборудование, но VMware рекомендует включать EVC в кластерах со старта, так как, во-первых, никто не знает, какое оборудование будет докупаться в будущем, а, во-вторых, так будет легче обеспечивать миграцию виртуальных машин между облачными инфраструктурами.
Основная причина, по которой не включают EVC - это боязнь того, что поскольку машины не будут использовать весь набор инструкций CPU (особенно самых последних), то это даст снижение производительности. Поэтому VMware написала целый документ "Impact of Enhanced vMotion Compatibility on Application Performance", где пытается доказать, что это не сильно влияет на производительность. Вот, например, производительность Oracle на выставленных базовых уровнях для разных поколений процессоров (в документе есть еще много интересных графиков):
Чтобы включить EVC на базе виртуальной машины, нужно ее выключить, после чего настроить нужный базовый уровень. Для автоматизации этого процесса лучше использовать PowerCLI, а сама процедура отлично описана в статье "Configuring Per-VM EVC with PowerCLI".
Для того, чтобы выяснить, какие базовые уровни EVC выставлены для виртуальных машин в кластере, можно использовать следующий сценарий PowerCLI:
Get-VM | Select Name,HardwareVersion,
@{Name='VM_EVC_Mode';Expression={$_.ExtensionData.Runtime.MinRequiredEVCModeKey}},
@{Name='Cluster_Name';Expression={$_.VMHost.Parent}},
@{Name='Cluster_EVC_Mode';Expression={$_.VMHost.Parent.EVCMode}} | ft
Это даст примерно следующий результат (надо помнить, что отчет будет сгенерирован только для VM hardware version 14 и позднее):
В примере выше одна машина отличается от базового уровня хостов, но в данном случае это поддерживаемая конфигурация. Проблемы начинаются, когда машина использует более высокий базовый уровень CPU, чем его поддерживает хост ESXi. В этом случае при миграции vMotion пользователь получит ошибку:
Понять максимально поддерживаемый режим EVC на хосте можно с помощью команды:
В целом тут совет такой - включайте режим Enhanced vMotion Compatibility (EVC) в кластерах и для виртуальных машин VMware vSphere сейчас, чтобы не столкнуться с неожиданными проблемами в будущем.
Напомним, что о версии HCIBench 2.0 мы писали вот тут, а здесь мы рассматривали использование этой утилиты для замеров производительности кластеров VMware vSAN. Напомним, что это средство позволяет провести комплексный тест производительности отказоустойчивых кластеров хранилищ Virtual SAN, а также других конфигураций виртуальной инфраструктуры.
Проект HCIbecnh ("Hyper-converged Infrastructure Benchmark") является оберткой для известного open source теста VDbench, он позволяет организовать автоматизированное тестирование гиперконвергентного кластера (HCI-кластера). Гиперконвергентный кластер - это когда все его вычислительные ресурсы, системы хранения и сети виртуализованы и собраны в единую интегрированную сущность и управляются из одной точки.
Целью такого тестирования может быть, например, необходимость убедиться, что развернутая инфраструктура обеспечивает достаточную производительность для планируемой на нее нагрузки.
Что нового появилось в HCIBench 2.1:
Интерфейс переключили на темную тему.
Переработанная технология подготовки VMDK, которая теперь работает гораздо быстрее за счет использования рандомизации на дедуплицированных хранилищах.
Добавлена возможность обновления процесса подготовки VMDK.
Добавлена проверка портов базы данных Graphite в процесс превалидации.
Пароли vCenter и хостов ESXi затемняются при сохранении
Очень часто администраторы платформы VMware vSphere задаются следующими вопросами о версиях продукта vCenter: какая разница между обновлением vCenter (он же update) и патчем (patch)? в чем отличие апгрейда (upgrade) и миграции (migration)? почему некоторые версии vCenter нумеруются как-то отдельно? Попробуем дать ответы на эти вопросы ниже, используя материал вот этой статьи в блоге VMware.
Первое, что нужно понять - это нумерация версий vCenter. Она подразумевает 2 компонента - номер версии (например, vCenter 6.7 Update 2a) и номер билда (например, 13643870):
Номер версии имеет также и цифровое обозначение. Если вы зайдете в интерфейс VMware Appliance Management Interface (VAMI), то увидите там номер билда (13643870), а также полный номер версии (6.7.0.31000):
Если же вы зайдете в vSphere Client и перейдете там на вкладку Summary для вашего сервера vCenter (в данном случае vCenter Server Appliance, vCSA), то увидите там версию 6.7.0:
В данном случае в поле Build указан номер билда клиента vSphere Client (13639324), и не стоит его путать с номером билда самого vCenter. Все это как-то более-менее соотносится между собой (VAMI дает более полную информацию о цифровом номере версии).
Теперь, чтобы сложить все это в единую картину и соотнести с датой релиза конкретной версии vCenter, существует статья базы знаний KB 2143838, где есть полезная табличка:
Обратите внимание на последнюю колонку - Client/MOB/vpxd.log. Это версия клиента vSphere Client, и именно она появится в лог-файле vpxd.log, поэтому не стоит удивляться, что она отличается от номера билда vCenter.
Теперь перейдем к апдейтам и патчам. vCenter Server Update - это полноценное обновление платформы, которое может включать в себя новый функционал, исправления ошибок или доработки существующей функциональности. Выходит апдейт довольно редко и имеет свое строковое наименование (например, vCenter 6.7 Update 2a). Для апдейта всегда выпускается документ Release Notes, и его можно скачать через my.vmware.com.
Патч - это постоянно выпускаемое небольшое обновление для vCenter, которое поддерживает уровень безопасности, закрывает критические уязвимости, исправляет фатальные ошибки и т.п. Он может относиться к вспомогательным компонентам vCSA, например, Photon OS, базе данных Postgres DB или фреймворку Java.
Для патча нет выделенного документа Reelase Notes, но информация о нововведениях доступна в VMware vCenter Server Appliance Photon OS Security Patches. Патчи нельзя скачать через my.vmware.com, но они загружаются через VMware Patch Portal. Само собой, патчи включаются в апдейты, выпускаемые на какой-то момент времени. Патчи накатываются в рамках одного цифрового обновления. То есть 6.7 Update 1 не патчится напрямую на 6.7 Update 2b, сначала надо накатить апдейт 6.7 Update 2a, а затем уже пропатчиться на 6.7 Update 2b.
Также на VMware Patch Portal вы можете найти ISO-образы vCenter Server, но их не надо использовать для новых развертываний, они нужны только для восстановления вашего vCenter Server Appliance, если вы используете резервное копирование на уровне файлов.
Теперь перейдем к разнице между апгрейдом и миграцией. Апгрейд - это обновление мажорной версии сервера vCenter одного типа развертывания (например, вы делаете апгрейд vCenter Server Appliance 6.5 на vCenter Server Appliance 6.7). Миграция - это когда вы меняете тип развертывания vCenter, переходя, например, с Windows-платформы на Linux (к примеру, vCenter Server 6.5 for Windows мигрируете на vCenter Server Appliance 6.7).
Если вы обновляете vCSA 6.5 на 6.7, то апгрейд идет как бы ненастоящий - развертывается новый виртуальный модуль vCSA 6.7, и на него переезжают все настройки (FQDN, IP, сертификаты и UUID), а также содержимое базы данных vCSA 6.5.
Также надо упомянуть и back-in-time upgrade - это когда вы хотите обновить, например, vSphere 6.5 Update 2d на vSphere 6.7 Update 1. Прямое обновление тут не поддерживается, так как Update 2d для версии 6.5 вышел позднее, чем Update 1 для версии 6.7. То есть Update 2d содержит код, которого нет в Update 1, а значит это может вызвать потенциальные конфликты.
Поэтому для каждой новой версии vCenter выпускается раздел Upgrade Notes for this Release, где можно найти информацию о возможности апгрейда:
У средства обновления хостов VMware vSphere Update Manager (VUM) есть полезный механизм проверок Pre-Check Remediation Report, который выполняет предварительную проверку условий для обновления хостов ESXi, чтобы этот процесс не прервался уже после его начала. Эти условия очень просты, но иногда позволяют сэкономить массу времени, особенно в большой инфраструктуре VMware vSphere.
Чтобы запустить эти проверки, надо выбрать нужный вам кластер и нажать кнопку Pre-Check Remediation:
После того, как вы запустите предпроверку Update Manager, вы получите отчет с предупреждениями о фактах, мешающих дальнейшим обновлениям:
Отчет Pre-Check Remediation Report для кластера может содержать следующие пункты:
Номер
Текущий статус
Рекомендуемое действие
Описание
1
Отключен ли DPM?
Отключите DPM в кластере
Если на хосте нет виртуальных машин, то механизм DPM может перевести хост в режим standby во время или до обновления. Вследствие этого, DPM может не начать процесс обновления хоста.
2
Включен ли DRS?
Включите DRS в кластере
Именно DRS позволяет серверу vCenter смигрировать ВМ на другие хосты ESXi, чтобы обновить целевой хост-сервер.
3
Отключен ли HA admission control?
Отключите HA admission control
HA admission control предотвращает миграцию ВМ средствами vMotion, в результате которой не выполняются правила доступности слотов. Перед обновлением этот механизм лучше отключить.
4
Включен ли EVC в кластере?
Включите EVC в кластере
EVC позволяет убедиться, что все хосты в кластере презентуют одинаковый набор инструкций CPU виртуальным машинам. Это позволяет гарантировать, что все они могут перемещаться на любой хост кластера средствами vMotion во время эвакуации машин с обновляемого хоста ESXi.
5
Успешны ли проверки vSAN health check?
Проверьте страницу vSAN Health Check на наличие проблем
Проверки vSAN Health Check представляют собой набор тестов для хостов ESXi, составляющих кластер vSAN (например, тесты доступности хранилищ во время обновления). Они должны завершиться успешно перед началом процедуры обновления хостов.
Отчет Pre-Check Remediation Report для виртуальных машин может содержать следующее:
Номер
Текущий статус
Рекомендуемое действие
Описание
1
К ВМ привязан привод CD/DVD
Отключите привод CD/DVD
Это редкая, но случающаяся проблема, когда такие приводы используются, например, для монтирования ISO-образов.
2
К ВМ привязан floppy-драйв
Отключите привод floppy
Очень редко, но бывает.
3
Для ВМ включена технология FT
Отключите Fault Tolerance для ВМ
Технология Fault Tolerance не позволяет VUM обновлять ВМ.
4
На ВМ установлен VMware vCenter Server, при этом DRS в кластере отключена
Включите DRS в кластере и убедитесь, что машина может мигрировать средствами vMotion
vCenter управляет компонентом VUM, поэтому нужно, чтобы он мог переехать на другой хост в процессе обновления ESXi.
5
На ВМ установлен VMware vSphere Update Manager, при этом DRS в кластере отключена
Включите DRS в кластере и убедитесь, что машина может мигрировать средствами vMotion
vCenter управляет процессом обновления, поэтому нужно, чтобы он мог переехать на другой хост в процессе обновления ESXi.
Компания VMware опубликовала уведомление VMSA-2019-0009 для пакета VMware Tools, который содержит уязвимость, позволяющую непривилегированному пользователю читать данные из гостевой ВМ, а также негативно влиять на ее гостевую ОС. Уязвимости подвержены версии VMware Tools ниже 10.3.10.
В качестве примера использования такой уязвимости можно привести Windows-машины, где включены службы Microsoft Remote Desktop Services. Также риску подвержены службы Microsoft SQL Server или IIS, использующие сервисные аккаунты.
Сначала надо вывести все ВМ, имеющие VMware Tools версии ниже 10.3.10 с помощью следующей команды PowerCLI:
Проверить версию VMware Tools можно и самостоятельно в VMware vSphere Client:
Помните, что VMware 6.7 Update 2a идет с версией VMware Tools 10.3.5. Надо отметить, что гостевые ОС Linux не подвержены уязвимости, поэтому не пугайтесь, что open-vm-tools имеют только версию 10.3.5.
Если вы хотите обновить VMware Tools через офлайн-бандл, то скачайте "VMware Tools Offline VIB Bundle", после чего можно использовать vSphere Update Manager (VUM) для развертывания установщиков пакета на хостах ESXi без простоя. После этого машины должны в течение 5 минут схватить новую версию тулзов (таков период обновления информации об актуальной версии пакета). Установленная версия VMware Tools также проверяется и при vMotion, а, кроме того, и при операциях с питанием ВМ (включение/выключение).
Помните, что при апгрейде VMware Tools вам может потребоваться перезагрузка виртуальных машин и их гостевых ОС. Также вы можете использовать приведенный выше сценарий для нескольких ВМ в одной папке:
Через vSphere Client тулзы также прекрасно обновляются:
Если вы используете опцию "Automatic Upgrade", то машина будет обновлена автоматически (без взаимодействия с гостевой ОС) и, при необходимости, перезагрузится. Также вы можете использовать обновление тулзов без немедленной перезагрузки, применив инструкции, описанные в KB1018377. Надо помнить, что в этом случае до перезагрузки будет работать старая версия VMware Tools, а значит, что до перезагрузки машины уязвимость будет актуальна.
Еще одна опция - настроить обновления тулзов в настройках виртуальной машины:
Иногда администраторы гостевой системы имеют эксклюзивный доступ к ней (например, админы бизнес-критичных баз данных) и контролируют все происходящие в ней события. Для этого надо настроить их взаимодействие с машиной как указано в KB 2007298.
В этом случае они получат нотификацию о новой версии VMware Tools из трея, либо могут проверить наличие обновлений самостоятельно с помощью команд:
RSS
